1. Field of the Invention
The present invention relates to the field of computer system interfaces and, more particularly, to the installation, versioning, and execution of applications on an application server.
2. Description of the Related Art
As is well known, computer files are stored in a storage medium (e.g., disk) using a directory structure. The “address” of a file is the storage location from where it can be retrieved and typically comprises one or more directory segments and a file name. This address is referred to as the “absolute path” of the file. As an example, in a Windows environment, the absolute path “D:\Workspace\Projects\ExampleApplication v01” identifies a file with the filename “ExampleApplication v01” stored on the “D drive” of a Windows-based computer in the subdirectory “Projects” of the directory “Workspace”.
The Java 2 Platform Enterprise Edition (J2EE) specification defines a standard architecture that has received widespread industry support and growing customer acceptance, and increased investment focus has been placed on J2EE technology by the industry. In accordance with the Sun J2EE specification, an enterprise application is packaged in a well known archive file format, and the packaged application is called an Enterprise Archive, or EAR file. A typical J2EE application comprises multiple archive files, referred to as “modules” and “utility JARs.” These archives may also be known as “nested” archives. When an enterprise application is deployed on an application server, it is common for the top level EAR file to be expanded into a directory structure on disk. The nested archives in the expanded EAR file are then located as files or directories directly under the root directory location of the EAR file.
A module in the context of J2EE architecture is a specialized kind of JAR file, containing Java classes and a deployment descriptor. A deployment descriptor is a configuration file that contains deployment information instructing an application server running the program how to deploy the enterprise application. A utility JAR file is a common JAR file that contains compiled Java classes that are referenced by Java classes in one or more other module or JAR files in the enterprise application. As noted above, all modules and utility JARs are relative to the EAR file that contains them.
It is not uncommon for the nested JAR files to themselves contain nested JAR files. An example is a WAR file as described in the Sun Java Servlet Specification, v2.2, by Sun Microsystems (Dec. 17, 1999). In addition to web pages and other assorted files (e.g., graphics), a WAR file may contain “libraries”, which are JAR files containing compiled programming code to be utilized by the web application.
With software in general, and in particular, in J2EE architecture, software applications, modules, and JARs are continually being modified, upgraded, corrected, and enhanced. Sometimes these changes are major and visible to the user and other times the changes are minor and/or affect “behind the scenes” activity with respect to the program, module, etc. Sometimes the modification of a program or module can cause errors in the overall program in its operation. In addition, sometimes the changes turn out to be less than desirable for the user.
Typically, software is given “version numbers” to indicate the particular version of a software element. Thus, for example, in the above example, the program “ExampleApplication v01” may be modified, creating “ExampleApplication v01.1” or “ExampleApplication v02”. Typically, when new versions of programs are installed, they overwrite the existing version. Thus, for example, when a user of ExampleApplication v01 upgrades the software to ExampleApplication v02, the user no longer has access to the version v01.
If all software worked properly, and all upgrades were desirable by users, the overwriting of an old version would not present a significant problem. However, in reality, it is quite common for software to experience bugs due to, for example, the operating system upon which it is running, the hardware on which it is installed, and other similar issues. Thus, situations often arise where a user would like to revert back to a previous version of a program or module within a program. However, due to the above-described overwriting of the earlier version, this typically requires the user to locate the old version, typically stored on a LAN file system or in a code repository, reinstall the old version, and thereby lose the new version.
Other situations may arise where a user wishes to use one version (e.g., ExampleApplication v01) for one particular process and use a different version (ExampleApplication v02) for a different process. However, given the overwriting process described above, this is not possible. Ad hoc solutions to this problem do exist. For example, a user may install a new version of software in a separate directory or store it in a separate storage location. This requires that the user recall where it is stored and find the other desired version when necessary. The problem is magnified when it is considered that application servers are designed to run web-based programs that serve very large numbers of users, and “down time” must be kept to a minimum. Therefore, updates to modules in an application, and rollbacks when such updates are determined to have caused problems, must be done in such a way as to minimize the impact to the running programs.
A solution developed for use with Websphere by IBM involves the concept of “loose files”, also known as “loose modules” or “loose archives.” This solution is described in detail in commonly-assigned, copending U.S. application Ser. No. 10/284,633, filed on Oct. 31, 2002, the disclosure of which is incorporated fully herein by reference. Loose files are simply files that are stored outside of the directory structure of the expanded EAR, i.e., they are not contained in a subdirectory of the EAR. For example, an EAR might contain a module named “myEJBs.jar”. Normally, “myEJBs.jar” would be a file located directly in the directory of the expanded EAR. In this solution, however, rather than store the nested archive contents within the file structure of the EAR file, contents are placed in separate locations in another directory. This enables the application server to piece together an application from separately located modules and JARs spread across the file system.
To coordinate the interaction between directories making up an enterprise application and mapping the loose files for use at runtime, this solution utilizes the above-described file structure and a “loose configuration file” to store the absolute paths of the nested archives.
This implementation is still limited, however, in that only one version of an application, or of a module contained by an application, can exist on the application server at any one time. What is needed is an implementation, using the aforementioned loose configuration, which allows multiple versions of applications and the modules contained therein to coexist on the same machine, and to allow the server to seamlessly update, rollback, start, and restart said components.